home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 4205 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.7 KB  |  87 lines
  1. Newsgroups: comp.lang.c
  2. Path: news.sprintlink.net!eskimo!scs
  3. From: scs@eskimo.com (Steve Summit)
  4. Subject: Re: realloc question
  5. X-Nntp-Posting-Host: eskimo.com
  6. Message-ID: <DM5tEn.BFo@eskimo.com>
  7. Sender: news@eskimo.com (News User Id)
  8. Organization: schmorganization
  9. References: <4ehi4b$qfo@news.texas.net>
  10. Date: Fri, 2 Feb 1996 17:47:10 GMT
  11.  
  12. In article <4ehi4b$qfo@news.texas.net>, gcherer@millenium.texas.net writes:
  13. > Whether i am on my old 286 with 1 meg, or on my 486 with 8 meg of ram, i 
  14. > get the same result when i do a realloc on about the 50th iteration.( its
  15. > on an array of pointers). but, when i compile and run the same program on 
  16. > a unix box (with beacoups more memory) it runs with no probs.
  17. >...
  18. > x++;
  19. > ptr=(struct sumthin**) realloc(ptr,(x+1) * sizeof(struct sumthin));
  20. > ptr[x]=(struct sumthin*) calloc(1,sizeof(struct sumthin));
  21. > 
  22. > Any ideas?? Sure preeeeeciate 'em. TIA
  23.  
  24. There are three possible problems that I can see:
  25.  
  26.      1.    You're simply running out of memory.  (You already
  27.     thought of that one.)
  28.  
  29.      2. The typo you made in the code fragment above also appears
  30.     in the code you're running, and you're allocating much
  31.     more memory than you need for the struct sumthin pointers,
  32.     and wasting (not using) most of it.  The second line
  33.     should read
  34.  
  35.         ptr = (struct sumthin **)realloc(ptr,
  36.             (x+1) * sizeof(struct sumthin *));
  37.  
  38.     (This is easy to spot, if you remember the rule that
  39.     there should always be one more * in the cast than in the
  40.     sizeof.  On the other hand, the explicit cast isn't
  41.     really recommended any more.)
  42.  
  43.      3.    You're fragmenting memory, so that although there's an
  44.     amount of total free memory available which is greater
  45.     than or equal to your request, it's not contiguous and
  46.     no one piece is big enough to satisfy your request.
  47.  
  48.     This is most likely your problem, because the calling
  49.     pattern you've shown turns out to fragment memory in the
  50.     worst possible way, if malloc and realloc are using the
  51.     obvious "first fit" allocation.  I've sent you a longer
  52.     description in e-mail (which anyone else is welcome to on
  53.     request), but basically what happens is that the array of
  54.     struct sumthin pointers leapfrogs through memory, leaving
  55.     a trail of successively larger holes behind it, each
  56.     guarded on either side by a block of struct sumthin which
  57.     you don't free or reallocate, and each too small for the
  58.     larger and larger arrays of struct sumthin pointers you
  59.     keep wanting.
  60.  
  61. There are several ways to work around this last problem.  You can
  62. use a version of malloc that doesn't use such a simpleminded
  63. first-fit strategy, and which therefore doesn't fragment memory
  64. so badly in the face of this calling pattern.  (It's likely that
  65. the Unix machine you tried the program on, besides having more
  66. memory, also used a different malloc algorithm, since the simple
  67. first-fit algorithms perform very badly in a virtual memory
  68. environment anyway.)  You can dig into your existing malloc and
  69. tweak its search behavior on the fly (I've occasionally done
  70. this), but of course this is completely nonportable and ties you
  71. to a particular malloc implementation and isn't generally
  72. recommended.
  73.  
  74. Finally, you can change your memory allocation pattern.  One easy
  75. fix (which I've used to success when I've had exactly this
  76. problem, on my poor old PDP-11 with 64K) is to grow your array of
  77. struct sumthin pointers in chunks of 10 or 50 at a time, instead
  78. of 1 at a time.  (In this case, you have to keep track of two
  79. counts, one of how many pointers you've allocated and one of how
  80. many of them you're using).  You may still fragment memory in
  81. this case, but not nearly so quickly or so badly.  Yet another
  82. solution would be to use a linked list, so that you wouldn't need
  83. contiguous arrays of pointers at all.
  84.  
  85.                     Steve Summit
  86.                     scs@eskimo.com
  87.